智能家居安全研究:身份劫持 | 您所在的位置:网站首页 › 54321端口 智能家居 › 智能家居安全研究:身份劫持 |
本文首发自公众号EnsecTeam,作者挽秋 智能家居身份和劫持危害 先通过一张简图来了解一下应用、智能设备和云端三者交互时携带的身份标识,如图所示: 智能家居设备交互时携带的身份标识 从上图了解到,智能家居身份标识通常是以下几种情况:1. 账号cookie相关,如身份Token; 2. 用户id:userid3. 设备id:deviceid4. 认证或加密的key一旦用户或设备的身份被劫持,那么至少存在如下几方面危害:1. 个人信息,聊天内容等隐私敏感信息泄露 2. 智能设备被任意控制3. 财产损失4. 随时被监控以智能音箱和智能插座等设备为例,至少有两个环节设计“身份”相关:1. 账号同步 2. 设备交互操作下面将分别介绍如何在这两个环节进行身份劫持。账号同步 账号同步是指,在智能设备在初次激活使用(或更改绑定用户时),用户将自己的身份信息同步给设备,并绑定设备。 一个简化的账号同步流程,如图所示:账号同步 账号同步通常会存在如下两类问题: 如何设备是否合法:验证设备id还是设备key?id和key都很容易泄露伪造。 账号Token如何安全传输:设备此时为入网,通过蓝牙、AP,还是其他何种方式传输账号信息。 账号同步时身份劫持,以厂商A音箱的配网和身份账号同步为例,其账号同步分为两种方式: 1. 直接通过UDP广播255.255.255.255:50000,发送userid、token和wifi的ssid和wifi密码。2. 将userid、token、ssid和wifi密码等转化成语音播放,音箱进行语音信息识别即可。关于两种模式的选择:由本地sharedPreferences文件(tg_app_env.xml)中的app_connect_mode属性值决定,其账号同步代码如图所示:厂商A音箱的账号同步 厂商A的音箱将身份信息,通过固定“协议”的格式,在UDP255.255.255.255:50000端口进行身份信息发送,攻击者可以监听UDP50000端口,从而获取用户的userid和token,窃取身份凭据;语音发送也是按照同一套固定的“协议”格式发送。协议格式通过破解后如图所示: 厂商A音箱的账号信息同步格式 设备交互 设备交互是指应用、设备和云端的三者交互访问;交互操作大体分为两种方式: 1. 只支持广域网:厂商A为代表;2. 支持广域网和局域网:厂商B和C为代表。广域网交互中应用与设备交互、设备与设备的交互方式如图:应用和设备广域网交互 设备和设备广域网交互 厂商A的智能家居接入方式:以开灯为例 第一步:厂商A的音箱-->音箱serverurl:https://***.com/***Payload: { Uderid, Deviceid, Accesstoken, 打开灯的语音}第二步:厂商A的音箱sever-->第三方server用户需要在第三方产品server注册并通过Oauth授权给厂商A的Server,消息格式如下:{ "header":{ “namespace”:”***Genie.Iot.Device.Control", "name":"TurnOn", "messageId":"1bd5d003-31b9-476f-ad03-71d471922820", "payLoadVersion":1 }, "payload":{ "accessToken":"access token", "deviceId":"34234", "deviceType":"XXX", "attribute":"powerstate", "value":"on", "extensions":{ "extension1":"", "extension2":"" } } } 第三步:第三方server-->设备 Payload:{command: turn-on, currentValue:0 }厂商A音箱的身份劫持厂商A的音箱每次交互时,都会携带: token、userid、deviceid、action来进行,并且server会依据userid来进行身份判断。1)有了userid就可以身份劫持——远程设备任意操作;2)userId是顺序的,可遍历的9位数字:比如一个userid是50****123,另一个userid则是50****397这几位数字; 3)userid还有其他多种方式获得:配网时窃取、APP端上获取;厂商A音箱被劫持后,可以用户查看聊天记录,自定义问答,设置闹钟、话费充值、智能家居控制等等,此外音箱 “被分享”之后,宿主不能主动取消分享,只能等“攻击者”取消分享,身份劫持危害如图所示,中间的攻击者可以任意查看用户的聊天记录:厂商A音箱的身份劫持 如何发现这类身份劫持? 应用或设备通过携带4元组信息:userid、deviceid、token和action,向云端进行请求时,如下图所示,如果云端对4元组信息校验出现不一致的情况下,就会导致身份劫持: 把userid、deviceid、token三者信息中的一种直接当成用户身份,而不是进行严格的身份一致性判断:判断userid和token是否一致,用户身份和设备列表是否是绑定关系。用户身份和action判断,存在逻辑漏洞,导致攻击者可以进行操作提权,比如子设备提权可以操作“属主”身份的一些权限,OTA更新等等。局域网交互中应用与设备交互、设备与设备的交互方式如下图所示: 应用和设备局域网交互 设备和设备局域网交互 厂商B的设备局域网身份劫持 在同一局域网下,厂商B设备通过专有的加密UDP网络协议——miio协议,进行通信控制。 1)通过广播发送一个握手协议包,如果设备支持miio协议,那么设备就会回复自身信息:token、ip和ID。2)向指定设备发送一串hello bytes获得设备信息结构体”header”3)凭借token、ID等信息构造信息结构体”header”,跟随控制消息发送给设备,实现设备控制。厂商B的设备局域网身份劫持交互如图所示: 厂商B的设备局域网身份劫持交互 第一步:安装python-miio库,然后执行:mirobo discover --handshake 1,获取设备IP、ID和Token信息。
Header, cmd, checksum }Msg控制消息结构体如图所示: 厂商B的设备控制消息结构体 以打开智能插座为例:cmd={'id':1,'method':'set_power','params':['on']} 厂商C的局域网交互控制厂商C为了实现智能家居生态,主推一套实现产品智能化互联互通的协议——“***Link”,目前所有的产品都可以与APP,以及音箱进行交互控制,是一套“带认证的密钥协商+对称密钥加密”的设备操作和交互控制协议。再介绍和认识“带认证的密钥协商”之前,我们先介绍一下ECDH密钥协商及其存在的安全问题。有两个用户Bob和Alice,使用ECDH密钥协商,交互过程如图所示:ECDH密钥协商 但是ECDH密钥协商是无法防御中间人攻击的,假设在Bob和Alice存在一个攻击者——Attack,对Bob和Alice进行中间人攻击,ECDH协商流程如图所示: ECDH密钥协商之中间人攻击 为了防御中间人攻击,需要在ECDH密钥协商过程中加入“一套身份认证机制”——EccSignKey和EccVerifyKey,EccVerifyKey提前存储在需要协商密钥的用户设备上,整个“待认证的ECDH密钥协商”交互过程如图所示: 待认证的ECDH密钥协商 设备和厂商C的应用(或音箱)基于***Link协议来进行交互,第三方设备制造商首先在云端通过ECC算法一对生成公私钥:Ecc-sPrivateKey/Ecc-sPubkey,其中公钥Ecc-sPubkey内置在设备端,用于发送随机数到云端,进行设备的身份认证,设备认证合法后,云端下发设备后续通信加密的key:accessKey,然后应用使用ECDH密钥协商算法协商出的密钥,通过AES-CBC模式加密传输accessKey;此外设备和应用进行局域网通信时,都是通过localkey进行加解密来进行的,其中localkey就是accessKey。设备和厂商C的应用局域网交互流程如图所示: 设备和厂商C的应用局域网通信交互 厂商C的设备局域网身份劫持 厂商C的***Link协议的交互控制的消息结构体如下所示:
“cmd”:5, "data":{ "streams":[{"current_value":"0","stream_id":"power"}], "snapshot":[{"current_value":"1","stream_id":"power"}] }设备交互方式总结和比较 属性\公司 厂商A 厂商B 厂商C 交互方式 只允许云端交互 允许云端和局域网 允许云端和局域网 是否可劫持 音箱server和第三方设备进行控制协议交互; 身份凭证是userid,可劫持 生态链企业,云端统一走厂商B的生态链云;基于miio协议 局域网交互,身份凭证token可劫持 第三方企业使用其link协议,云端使用厂商C的云作为server;局域网交互依赖localkey,目前安全。但是设备身份依赖于ECC-sPubKey(多个设备一个key),该key失窃后,设备可以被伪造。 产品安全性负责 厂商A只负责自己音箱自生的安全性,第三方产品的安全性自行负责。 厂商B负责 第三方自己负责,但是***link协议统一交互控制、OTA更新等,安全性极大的有保障 账号 第三方Oauth登录授权 统一厂商B的帐户 厂商C的帐户 APP控制 第三方有独立APP 厂商B的APP 厂商C的APP(H5小程序) 通过应用实现身份劫持 通过应用实现身份劫持,常用的方法有如下两种: 1)通过webview JS交互接口远程命令执行或泄露身份账号 应用APP通过为webview @JavascriptInterface关键字,自定义添加身份获取的函数,并且没对加载url做好限制,导致身份信息远程泄露或者远程命令执行2)Webview file域远程信息泄露 应用开启WebSettings.setAllowUniversalAccessFromFileURLs(true),并且webview对加载的url没有任何限制,则应用APP下所有私有目录信息都会被窃取通过webview JS交互接口远程命令执行或泄露身份账号应用扫一扫时(CaptureActivity),当CaptureActivity扫描到是“合法”url时,会调用com.***.WebViewActivity进行url加载,但是url判断逻辑存在漏洞,导致攻击者可以调用WebViewActivity定义的交互接口,远程获取用户账号等敏感身份信息,漏洞执行效果如下图所示。 通过webview-JS交互接口获取厂商C控制应用的身份 漏洞案列简化: if(loadurl.contains(“***”)){//合法 } else{//不合法 }Webview file域远程信息泄露 厂商A的音箱控制APP中WVWebViewActivity对外导出,并接收如下远程uri scheme:assistant://hsend***Poc5_web_view?direct_address=url。
智能家居身份劫持漏洞总结 1. 配网泄露 2. 设备交互控制时,劫持1)app/设备->server:厂商A为代表,userid为身份凭证,可劫持;2)局域网控制:厂商B的局域网控制基于miio协议:token泄露,可劫持厂商C的微联局域网控制:带认证的密钥协商+对称密钥加密(localkey),协议安全;3. app应用存在身份穿越漏洞 Webview JS交互接口远程命令执行或远程信息泄露Webview File域远程信息克隆参考文献 1.https://github.com/WeMobileDev/article/blob/master/%E5%9F%BA%E4%BA%8ETLS1.3%E7%9A%84%E5%BE%AE%E4%BF%A1%E5%AE%89%E5%85%A8%E9%80%9A%E4%BF%A1%E5%8D%8F%E8%AE%AEmmtls%E4%BB%8B%E7%BB%8D.md 2. https://github.com/rytilahti/python-miio3.https://paper.seebug.org/616/声明:本文来自EnsecTeam,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 [email protected]。 |
CopyRight 2018-2019 实验室设备网 版权所有 |